With the advent of the computer age, computer and software users have grown accustomed to user-friendly software applications that help them write, calculate, organize, prepare presentations, send and receive electronic mail, make music, and the like. Modern word processing applications, for example, allow users to create and edit a variety of useful documents. Modern project management applications, as another example, allow users to create project management schedules for organizing and managing tasks, resources and labor associated with a variety of projects.
Manual and computerized project management systems allow managers and planners to organize and plan the tasks, resources and schedules required for completion of a given project. In most projects, a number of dependencies and constraints dictate the timing and completion of an overall project and of sub-projects comprising the overall project. For example, in a house construction project, a drywall sub-project may not typically begin until the completion of electrical work. And, a number of sub-projects may be constrained by the availability of labor and resources. Project management software applications have been developed for creating and automating project management schedules. With many such systems, tasks or sub-projects comprising an overall project are set out in scheduling charts, such as Gantt Charts, showing start dates and finish dates for given milestones and associated tasks comprising the overall project and providing information regarding utilized resources and constraints associated with the milestones and tasks comprising the project.
A commitment is an agreement between two people (or organizational entities) to fulfill a set of conditions. That is, commitments may be described as dependencies between two or more entities. For example, a first company team may commit to delivering a prototype of an application to a second company team by a date certain, Aug. 8, 2005. The team responsible for getting the work done is the “commitment provider”, while the team relying on the timely completion of the set of conditions is known as the “commitment consumer.” In this example, the commitment itself is the delivery of the application prototype.
In prior versions of Microsoft Project, this sort of dependency between projects was modeled using cross-project links (“CPLinks”). In Microsoft Project Standard, for example, to establish the dependency, a user would be required to open both projects and drag a dependency link from one task in one project to the other task in the other project. That is, CPLinks provided a tightly coupled implementation where a task from one project was imported into another project at a client station. Moreover, with CPLinks, a dependency that spans from one task in a project A to another task in a project B is treated the same way as two tasks in the same project are treated. Whenever the originating task changed by any means, the task was updated in any project that linked to the affected task. This automatic process can be very invasive to all of the projects involved, a potentially unacceptable result for a project manager of an affected project.
For example, a change in a task in project1 could result in a cascading update in project1 where a cross project linked task had one or more dates affected. The cross project linking system would then open up linked projects, project2 and project3, for example, and update the mirror of the linked task in those projects. This would often result in complete schedule shifts in the affected projects with no mechanism to undo the changes or to stop the changes from occurring. To complicate matters further, project2 and project3 might provide CPLinks themselves that are modified during the initial CPLink update. This would cause all of the projects relying on project2 and project3 to be opened and updated.
Basically one of the problems that customers face today when they're managing multiple projects is handling dependencies that span various projects. For example, assume two projects exist, project A and project B. Project B may have dependencies (i.e. tasks, resources, etc.) which depend on project A and vice versa. Customers face a fairly difficult problem managing those dependencies between projects. When something affects a task in project A, project B would like to know about it.
Currently, the task in project A is reflected “as-is” in project B. This results in a lot of “noise” as even a small change of date in project A affects project B's schedule. In the real-world, a project manager that has a commitment to another project usually would like to control the date “visible” to the other project, and allow the task in his project some buffer prior to the actual commitment date. On the flip side, project manager of project B would like to control how task changes in dependent projects affects his schedule.